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ABSTRACT 



A system and method which allows the interchange of 
Cookie information and standard Common Gateway Inter- 
face (CGI) variables between a user system and an On-line 
Transaction Processing (OLTP) enterprise server. The 
present invention also discloses a specialized form of a 
transaction gateway, known as a security gateway, which 
runs on a Windows NT or UnixWare Web Server machine, 
and is built as a client application to intemperate with an 
enterprise-based OLTP security service. Finally, the present 
invention discloses an enterprise-based OLTP security 
service, which is used in conjunction with the security 
gateway described above, which processes user generated 
authentication requests, and if successful, calls an end 
service requested by a user. 

35 Claims, 8 Drawing Sheets 
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MAKING CGI VARIABLES AND COOKIE One key to the future success of a business may lie in its 

INFORMATION AVAILABLE TO AN OLTP ability to capitalize on the growing prevalence of web 

SYSTEM browsers in combination with selectively providing access 

to the data that is stored in its databases. Common Gateway 

5 Interface (CGI) programs are used to provide web browser 
access to such databases. 

The present application is related to U.S. patent applica- The Common Gateway Interface (CGI) is a standard for 

tion Ser. No. 09/164,759, filed Oct. 1, 1998, entitled "A interfacing external applications, such as web browsers, to 

COMMON GATEWAY WHICH ALLOWS APPLETS TO obta in information from information servers, such as web 

MAKE PROGRAM CALLS TO OLTP APPLICATIONS 1Q ser vers. The CGI allows programs (CGI programs) to be 

EXECUTING ON AN ENTERPRISE SERVER", and appli- referenced by a web browser and executed on the Web 

cation Ser. No. 09/164,932, filed Oct. 1, 1998, entitled "A Server System. For example, to make a UNIX database 

MULTI-CLIENT USER CUSTOMIZED DCOM GATE- accessible via the World Wide Web, a CGI program is 

WAY FOR AN OLTP ENTERPRISE SERVER executed on the Web Server System to: 1) transmit infor- 

APPLICATION", both of which are assigned to the assignee 15 ma tion to the database engine; 2) receive the results from the 

of the present invention and incorporated herein by refer- database engine; and 3) format the data in an HTML 

cnce - document which is returned to the web browser. CGI vari- 

BACKGROUND OF THE INVENTION a ^ es typically include information such as the IP address of 

the browser, or the port number of the server. 

1. Field of the Invention j ■ . w • i- 1 * 
„ . 20 Often associated with CGI Variables, cookies are packets 
The present invention relates to a security system for of information which may besentbackto ausersystem after 

validating Web-Based requests and more specifically, to a ^ ^ & ^ ^ ^ ^ of infommtion 

security system whereby CGI Variables and Cookie infor- indicate how a uger ^ dous associatcd 

mation from a Web-Based client are passed via a security ^ ^ ^ ^ information wm be stored on the user 

gateway to an enterprise based OLTP security service for ^ syslem along with thc Uniform Resourcc !^ ator (U RL) for 

va i ation. me web & ^ and ^ e m f ormat j on [ s passed back to the server 

2. Description of the Prior Art tf the user accesses tne web site again 

The methods by which companies conduct business with Server ^ the uscr history prov ided by the 

their customers are undergoing fundamental changes, due in cookies l0 make decisions reg arding how the user request is 

large part to World Wide Web technology. In addition, the 30 tQ bc handkd For examp i e , assume me web site invo i ves 

same technology that makes a company accessible to the history ^ cookie in f oimation will inform the server that 

world, may be used on internal company networks for the current request is from a user interested in the Civil War. 

conducting operational and administrative tasks. ^ allows ^ XTVQr {Q provide the ^ with advertise- 

One of the technologies underlying the World Wide Web menls on ^ote related to the Civil War. 

is the web browser. Web browsers have become a de facto 35 There is a growing need for greater assurances that 

user interface standard because of their ability to interpret in f ormat i on be ing passed along the Internet is secure and 

and display information having standard formats (e.g., will not be intercepted. Some of the problems involved with 

HyperText Markup Language (HTML), standard test, GIF, Jnternet hacking include stolen access> stolen resourceS) 

etc.). Client software programs, popularly referred to as c . mail counterfeiting) vandalization, and Internet agents 

web-browsers (e.g., Mosaic, Netscape Navigator, Microsoft 40 (worms) (source: MaUeo Foschetti, Internet Security, Cali- 

Internet Explorer, etc.), execute on client systems and issue fomia S(ate Uruversity> FuUcrtonf April 1996, available 

requests to server systems. The server systems typically on _ Hne al . http://www.ecs.fullerton.edu/-foschett/ 

execute HyperText Transport Protocol (HTTP) server pro- se curity.html). Many consumers have the general perception 

grams which process requests from the web browsers and that transacting business on the Internet is not safe, thus they 

deliver data to them. The system that executes an HTTP 45 are reluctant t0 participate in Internet activities such as 

server program and returns data to the web browser will on . Hne shoppingj send i ng messages, submitting to 

hereinafter be referred to as a Web Server System. An HTTP ne wsgroups, or web surfing. Although some people's per- 

server program itself will be referred to as a web server. ccption of Internet security breaches may be somewhat 

A Web Server System has access to on-line documents overblown, figures do prove the vulnerability of the Internet, 

that contain data written in HyperText Markup Language so u has been estimated that over 80% of all computer crimes 

(HTML). The HTML documents contain display take place usiag the Inte met. With over 30,000 intercon- 

parameters, capable of interpretation by a web browser, and nectcd networ ks and 4.8 million attached computers includ- 

references to other HTML documents and web servers ing over 30 m ini 0 n users, there is a legitimate Internet 

(source: World Wide Web: Beneath the Surf, from UCL security concern. 

Press, by Mark Handley and Jon Crowcroft, on-line at 55 Businesses are faced with the challenge of adapting their 

http://www.cs.ucl.ac.uk/staff/jon/bookA>ook.html). presem of yeslerday > s technology to new opportuni- 

As web browsers are making their mark as a "standard" tics thal are madc available with the World Wide Web. Most 

user interface, many businesses have a wealth of information business application software and underlying databases are 

that is managed by prior art data base management systems not cqu i ppe d to handle interaction with web browsers. It 

such as DMS, RDMS, DB2, Oracle, Ingres, Sybase, 60 wou i d therefore be desirable to have a secure, flexible and 

Informix, and many others. In addition, many of the data- efficient means for allowing interoperability between 

base management systems are available as resources in a enterprise-based business application software and the 

larger transaction processing system. There are also mission World Wide Web. 
critical applications which still reside on enterprise servers, 

since these type of systems have resiliency and recovery 65 SUMMARY OF THE INVENTION 

features historically not available on other smaller types of The present invention overcomes many of the disadvan- 

servers. lages associated with the prior art by providing a system and 
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method which allows the interchange of Cookie information 
and standard Common Gateway Interface (CGI) variables 
between a user system and an On-Line Transaction Process- 
ing (OLTP) enterprise server. Previously, the interchange of 
Cookies and CGI variable information was confined 
between a user system and a web-server. 

In a preferred embodiment of the present invention, when 
a user accesses a selected web site from a web browser, 
packets of Cookies are passed from an On-Line Transaction 
Processing (OLTP) enterprise server to a user system. These 
packets of Cookies indicate how the user utilized various 
functions associated with the site. This information is stored 
on the user system along with the Uniform Resource Locator 
(URL) for the web site, and is passed back to the OLTP 
enterprise server if a user accesses the web site again. 

CGI Variables are also used to pass information between 
a user system and an enterprise OLTP server. These CGI 
variables can include information such as the IP address of 
the web browser or the port number of the web server. 

The present invention passes Cookies and CGI variables 
between a Personal Computer (PC) based web browser and 
an enterprise OLTP server via web server, WebTx server and 
transaction gateway interface components. 

The present invention also discloses a specialized form of 
a transaction gateway, known as a WebTx security gateway. 
This security gateway runs on a Windows NT or UnixWare 
web server machine, and is built as a client application to 
interoperate with an enterprise-based OLTP security service. 
In an illustrative embodiment, the security gateway receives 
a OLTP transaction request and associated Cookie/CGI 
Variable information from the WebTx server, builds a view 
file using the Cookie and CGI Variables, calls the enterprise- 
based OLTP security service, then waits for validation of the 
OLTP transaction request. The security gateway will even- 
tually receive a response from an OLTP security service 
indicating whether the request was validated by the OLTP 
server. If the request was validated, the security gateway will 
allow the request to be processed. That is, the security 
gateway builds a view buffer associated with the requested 
OLTP service, then passes the buffer to the requested OLTP 
service. 

The present invention also discloses an enterprise-based 
OLTP security service, which is used in conjunction with the 
security gateway of the present invention. This security 
service processes user-id authentication requests, and if 
successful, calls an end service requested by a user. 

The security service of the present invention offers several 
significant advantages over prior art security services. The 
present invention allows all request validation to be per- 
formed directly on the enterprise OLTP system. In the past, 
requests made to a gateway for access to an enterprise OLTP 
system were validated first on a workstation based gateway 
server. If the requests were found to be invalid, they were not 
passed on to the OLTP system. However, maintaining the 
updated validation information on a workstation as is nec- 
essary to validate such requests presents a large administra- 
tive burden. In addition, the security and resiliency aspects 
of an enterprise-based security service are superior to similar 
functionality available in a workstation based security ser- 
vice. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Other objects of the present invention and many of the 
attendant advantages of the present invention will be readily 
appreciated as the same becomes better understood by 
reference to the following detailed description when con- 
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sidered in connection with the accompanying drawings, in 
which like reference numerals designate like parts through- 
out the figures thereof and wherein: 

FIG. 1 is generalized block diagram of components uti- 
5 lized by the current invention, including a step-by-step 
illustration of a transaction as it proceeds through the 
components of the system; 

FIG. 2 is a functional block diagram of the computing 
environment in which the present invention resides; 

FIG. 3 is a block diagram showing the flow of CGI 
variables through the components of the computing envi- 
ronment; 

FIG. 4 is a flowchart illustrating a step -by-step process 
15 flow through the SGate transaction gateway; 

FIG. 5 is a flowchart illustrating the computer algorithm 
utilized by the SGate transaction gateway program; 

FIG. 6 is an illustration of the data structures utilized by 
the WebTx custom gateway; 
20 FIG. 7 illustrates a functional, block-level overview of the 
enterprise-based On-Line Transaction Processing (OLTP) 
System security service of the present invention; and 

FIG. 8 is a flowchart illustrating the enterprise -based 
On-Line Transaction Processing (OLTP) System security 
25 service program code. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

30 The detailed descriptions which follow are presented 
largely in terms of algorithms and symbolic representations 
of operations on data bits within a computer memory. These 
algorithmic descriptions and representations are the means 
used by those skilled in the data processing arts to most 

35 effectively convey the substance of their work to others 
skilled in the art. 

An algorithm is here, generally, conceived to be a self- 
consistent sequence of steps leading to a desired result. 
These steps are those requiring physical manipulations of 

40 physical quantities. Usually, though not necessarily, these 
quantities take the form of electrical or magnetic signals 
capable of being stored, transferred, combined, compared, 
and otherwise manipulated. It proves convenient at times, 
principally for reasons of common usage, to refer to these 

45 signals as bits, values, elements, symbols, characters, terms, 
numbers or the like. It should be kept in mind, however, that 
all of these and similar terms are to be associated with the 
appropriate physical quantities and are merely convenient 
labels applied to these quantities. 

50 Furthermore, the manipulations performed are often 
referred to in terms, such as adding or comparing, which are 
commonly associated with mental operations performed by 
a human operator. No such capability of a human operator 
is necessary, or desirable in most cases, in any of the 

55 operations described herein which form part of the present 
invention; the operations are machine operations. Useful 
machines for performing the operations of the present inven- 
tion include general purpose digital computers or other 
similar devices. In all cases, it should be kept in mind the 

60 distinction between the method operations in operating a 
computer and the method of computation itself. The present 
invention related to method steps for operating a computer 
in processing electrical or other (e.g., mechanical, chemical) 
physical signals to generate other desired physical signals. 

65 The present invention also relates to apparatus for per- 
forming these operations. This apparatus may be specially 
constructed for the required purposes or it may comprise a 
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general purpose computer as selectively activated or recon- bookseller web site. The enterprise based OLTP service 

figured by a computer program stored in the computer. The application 114 then reads the user Cookie information, and 

algorithms present herein are not inherently related to a passes back advertisements on books related to the Civil War 

particular computer system or other apparatus. In particular, to the web browser 100. If the user decides to purchase a 

various general purpose computer systems may be used with 5 book, transaction related cookie information which has 

computer programs written in accordance with the teachings already been passed to the end service application minimizes 

of the present invention, or it may prove more convenient to the amount of information that needs to be re-entered by the 

construct more specialized apparatus, to perform . the user. Finally, system access to sensitive transactional infor- 

required method steps. The required structure for such mation provided by the user during the ordering process 

machines will be apparent from the description given below, 10 (such as credit card numbers, personal identification 

FIG. 1 is a generalized block diagram of components numbers, etc.) is protected by a security component (security 

utilized by the current invention, including a slep-by-step gateway 110, and OLTP security service 112) which vali- 

illustration of a web transaction request as it proceeds dates the transaction before it is processed by the end service 

through the components of the system, U*- 

Web browsers 100 are the primary tool for viewing the 15 By way of definition, a security service is a UCS C code 

contents of information repositories on the World Wide Web. module supplied by Unisys and written in the form of a 

By further definition, a web browser 100 is a tool (software standard Open/On-Line Transaction Manager OLTP- 

application) used to view the contents of an item packaged TM2200 service (further described in the detailed descrip- 

in a format requiring decoding, deciphering or decryption. tion of FIG. 7). It processes user-id authentication requests 

Web browsers 100 read and display web pages. Web pages 20 and, if successful, calls an end service for that user. An end 

are merely text based characters arranged in a manner such service 114 is an OLTP-TM2200 service that needs to be 

that background and foreground colors, fonts (styles of executed by an Internet user. It can be a new generation 

characters), and images are transformed into the results of service or a Heritage Application Access (HAA) service, 

the intended web page. Thus, it is the job of the web browser Information that can be passed to the enterprise -based 

100 to interpret the HTML (arranged text characters) into the 25 OLTP security service application 112 from the web browser 

colors, fonts, and images that are presented to a user when 100 via an authentication view bufiFer or a security service 

accessing a web page. Examples of popular, commercial view buffer includes user identification information such as: 

web browsers 100 include "Navigator" from Netscape passwords, account numbers, user-id, the OLTP end service 

Corporation, and "Internet Explorer" from Microsoft Cor- name to call, and browser CGI variables. The Cookie and 

poration. 30 CGI information was passed to web server 106 via interface 

When a user accesses a web site, web browser 100 120, as shown in step 3. 

retrieves Cookie and CGI Information from an enterprise- In step 4, after the Cookie and CGI information has been 

based OLTP server. Cookies are packets of information successfully passed to the web server 106, the web server 

which may be sent back to a user system after a user accesses 35 106 determines if the request is for the WebTx Server 108. 

a web site. These packets of information indicate how the If so, the web server 106 (Microsoft IIS or Netscape 

user utilized various functions associated with the site. Enterprise/Fastrack) formats the CGI variables and Cookie 

Cookie information is stored on the user system (in Cookie information into one long string which is passed to the 

repository 102 and CGI repository 104), along with the WebTx Server 108 via interface 122. 

Uniform Resource Locator (URL) for the web site, and is CQ \ n step 5, the WebTx Server 108 understands the format 

passed back to the enterprise OLTP server if the user 0 f the long string passed by the web server 106, then 

accesses the web site (appropriate range of URLs) again. re-packages the variables into an array which is passed to 

Software on the enterprise OLTP server uses the user history whichever Gateway is associated with the request (such as 

provided by the Cookies 102 to make decisions regarding the security gateway shown at 111), via interface 124. The 

how the user request is to be handled. ^ WebTx security gateway 111 is a specialized WebTx gate- 

CGI Variables 104 are also used to pass information way that runs on a Windows NT or UnixWare web server 

between a user system (web browser) 100 and an enterprise machine. This gateway 111 is built as a client application to 

OLTP server. These CGI variables can include information intemperate in conversation mode with the OLTP-TM2200 

such as the IP address of the web browser 100, or the port security service. This code module can be customized to 

number of the web server 106. 50 meet environmental needs. 

A transact ion is a complete unit of work that maintains the In step 6, the security gateway 111 builds a security 

ACID properties (atomicity, consistency, isolation, and service view file using the Cookie and CGI variables, then 

durability) for the work it performs. Typically a transaction calls the On-Line Transaction Processing (OLTP) security 

updates one or more databases. In distributed transaction service 112 executing on an OLTP server (such as a Unisys 

processing (DTP), a transaction can include multiple units of 55 2200). The security gateway 110 passes the view buffer to 

work performed on one or more systems. the OLTP Security Service 112 via interface 126, then waits 

As an illustrative example of a transaction, a user accesses for validation of the request. The security gateway U0 will 

a web site of a bookseller specializing in historical books eventually receive a response from the OLTP security ser- 

through web browser 100. Already stored within the Cookie vice 112 indicating whether the response was validated by 

information repository 102 on the user system is a Cookie 60 &e OLTP security service 112. If the request was validated, 

which indicates a shipping preference for UPS second day the security gateway 110 will allow the request to continue 

air, a user preference for books on the Civil War, and various k> be processed. If the request was not validated by the 

other transactional information that has been previously security service 112, further access to the desired OLTP end 

entered by the user on a previous order. This Cookie service 114 is denied. 

information is passed from Cookie information repository 65 In step 7, after the request is validated by the security 

102 on the user system to an enterprise based OLTP end service 112, the security gateway 110 builds buffer subtype 

service application 114 as soon as the user re-enters the (view) associated with the requested OLTP end service 114, 
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and passes the buffer subtype to the OLTP security service from the Gateways 238, 240, 242, 244, 246, 248, 250, or 

112. A buffer subtype specifies exactly how the data in a 252, and route the reply. The Web Server Extension 228 is 

buffer is structured. This structure is defined according to the connected to the Gateways 238, 240, 242, 244, 246, 248, 

needs of an application program (service) and the database 250, or 252 via interfaces 211, 213, 215, 217, 219, 221, and 

information it uses. A properly formatted buffer subtype s 223. The Web Server Extension 228 is connected to the 

definition is called a view. The security service 112 will then Monitor 260 via interface 203. 

call the end service (the requested OLTP service application) The Gateways 238, 240, 242, 244, 246, 248, 250, and 252 

114 via interface 128 perform tasks which are grouped into conceptual areas. The 

T , Q ft * ^au ,<a-<* <i, Gateways 238, 240, 242, 244, 246, 248, 250 and 252 receive 

In step 8, after the end service 114 has completed its task, ' from the Web Server Extension 228 or from the 

l u 6 ™ ™ o"* reSU I ^ m a ° out P u '™ w file t0 10 Applications 258 and take whatever action is necessary to 

the OLTP Security Service 112 via interface 128. fulfill the request. This typically involves transforming a 

In step 9, the end service results are returned from the request (such as a URL from a web browser or remote 

OLTP Security Service 112 to the Security Gateway 110 via procedure calls (RPCs) from a DCOM client) into a format 

interface 126. The results will be in a view file format. which is understandable by a Distributed Transaction Pro- 

In step 10, the security gateway 110 unpacks the end 15 cessing System such as a Unisys 2200 Enterprise System 
service results from the view file, builds a populated web 200, The Gateways 238, 240, 242, 244, 246, 248, 250, and 
page and Cookie from information in said view file, and 252 als ^ 'transform data returned from the ; Distributed Trans- 
returns the web page and Cookie information to the WebTx ac ' l0n .Processing System 200 into a formatted response 
c mo • ■ . c Tu- u a \ ■ which is returned to the requester. 
Server 108, via interface 124. This web page and Cookie nn • -a .. a 
information will ultimately be passed back to the web 20 ^ f™P lc Gate Gateway 238 is specificaUy utilized as a 
t 1AA . lU . J ; nc test tool. It merely echoes a request. The TUXGate Gateway 

browser 100 via the web server 106. i- j * mTT1 . „f* 

240 provides generalized access to OLTP services through 

In step 11, the WebTx Server 108 passes back the popu- BEA TUXEDO 230. BEA TUXEDO 230 acts as the hub for 

lated web page and Cookie information to the web server a distributed enterprise and Internet 3-tier applications. It 

106, via interface 122 . 25 provides an open environment that supports a wide variety 

In step 12, the web server 106 passes back the Cookie of clients, databases, networks, legacy systems, and corn- 
information and populated web page to the web browser munications options. The FileGate Gateway 242 works in 
lOQ conjunction with a specific OLTP service to access textual 

In steps 13 and 14, any updated Cookie/CGI Variable files .° n the U "»J» 2200 n °^Jf' ewGate * h T own ) 

. c r j u i f >u u a - »u ™ provides generalized access to OLTP services on the Unisys 

information passed back from the web server is stored in the JU ^ & . , c „ ___.„ A AT/-. *\a< •/ 

Cookie 102 and CGI Variable 104 repositories on the user 2200 ™te (specifically HTML output) i. JGate 246 provides 

generalized Java applet access to OLTP services on the 

system 

3 . Unisys 2200 node. The DGate Gateway 248 provides gen- 
FIG. 2 is a functional block diagram of the computing era]ized qcOM access to OLTP services on the Unisys 2200 
environment in which the present invention resides. In node ^ Mapp6rGate Gateway 250 provides generalized 
general, WebTx is middleware in a client/server computing accesg to Mapper applications within the M i croso ft Win- 
environment which accepts requests from the client side and dows m environroent A Custom Gateway, such as shown 
routes the requests to the correct place on the server side, at 2 ^ ide a way for a customer t0 build their own 
then passes a response from the server side back to the client Gateway t0 interface their own applications to an OLTP 
side. In the context of the present invention, WebTx "mar- enterprise application. 

ries" a web browser 214 with a transactional cUent/server ^ ^ & } ^ of ^ 

architecture (such as the Unisys 2200 enterprise node, as oh] ^ > f ^ inycni ^ Tccci ^ C ookic information 210 

shown at 200). and CQ[ varia51es 2 u from a web browser 214 via the 

The WebTx environment, as utilized in the present We5Tx Web Server 2 26 and WebTx Web Server Extension 

invention, is comprised of several components, including a 45 2 28. The security gateway (SGate) 244 then builds a view 

web server 226, Web Server Extension (WTXMS.DLL or flle using the user identification information, CGI variables 

WTXNS.DLL) 228, a Monitor (WTXSVC) 260, one or 2 12, the end service name and Cookies 210, then calls a 

more Gateways 238, 240, 242, 244, 246, 248, 250, 252, the security service 216 executing on the OLTP server 200, 

Web ViewC compiler 256, a set of libraries 254, and other passes the view fiJe t0 the secur i t y service 216, and waits for 

special purpose tools 220. $Q validation of the request. The security gateway (SGate) 244 

The WebTx Monitor 260 communicates with the Web will eventually receive a response from the OLTP security 

Server Extension 228 via interface 203, and a Gateway 238, service 216 indicating whether the request was validated by 

240, 242, 244, 246, 248, 250, or 252 via interface 209. The the OLTP server. If the request was validated, the security 

Monitor 260 functions as the WebTx administrative tool. gateway (SGate) 244 will allow the request to be processed. 

One function of the Monitor 260 is to start and stop the 5S That is, the security gateway 244 will build a view buffer 

gateways 238, 240, 242, 244, 246, 248, 250, and 252, as associated with the requested OLTP end service 218, and 

needed. Within a Unix environment, the WebTx monitor will then pass the buffer to the OLTP server. If the request 

module is known as WebMon (not shown), while under the is not validated, further access to the OLTP service 218 is 

Windows NT environment, the WebTx monitor module is denied. 

known as WtxSvc 260. 60 The Web ViewC compiler 256 is used in conjunction with 

The WebTx Web Server Extension component 228, is a specific Gateway implementations, such as ViewGate, 

run -time extension of the web server 226 (such as Netscape TUXGate, and JGate. The Web ViewC compiler 256 com- 

FastTrack, Netscape Enterprise, or Microsoft IIS). The func- piles Open/OLTP view files generated on the OLTP enter- 

tion of the Web Server Extension 228 is to intercept requests prise system to create WebTx view files (.wv) and HTML 

intended for WebTx 204, and instead route the requests to 65 files (.html). The Web ViewC compiler is a free-standing 

the Gateways 238, 240, 242, 244, 246, 248, 250, or 252. The component with no direct communication to any of the other 

Web Server Extension 228 will also interpret the response components within the WebTx environment. 
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Other WebTx Components include libraries 254 such as 
the Software Development Kit (SDK) libraries, which pro- 
vide framework and functions for building Custom Gate- 
ways. The SDK is specifically designed to allow customers 
to build their own gateways. Another type of library present 5 
within the WebTx system are Java Class Libraries, which 
provide class definitions for building JGate compatible 
applets. 

FIG. 3 is a block diagram showing the flow of CGI 
variables through the components of the computing envi- i° 
ronment. The web server 300 contains request data from a 
web browser (i.e. data about the request itself). Examples of 
request data information include: what IP address made the 
request and who is the user. This request data is in the form 
of CGI Variables and Cookies, further described in the 15 
detailed description of FIG. 1, as shown above. 

The web server 300 will package and forward the request 
data (CGI Variables and Cookies) to the WebTx Web Server 
Extension 302 via interface 310. The WebTx Dynamic Link 
Library (DLL), a component of the WebTx Web Server 20 
Extension 302, obtains the request data from the web server 
300 (Microsoft IIS or Netscape Enterprise/Fastrack servers), 
re-packages the request data, then passes the re-packaged 
data to the specified WebTx gateway 320 via interface 314. ^ 

In order to collect data from the web server 300, the 
WebTx Dynamic Link Library (DLL) 302 makes calls to the 
web server 300 via Internet Server Application Program 
Interface (ISAPI) calls. The WebTx DLL 302 collects as 
much of the data as possible to populate the Gateway Data 3Q 
Structure, further described in FIG. 6. Some of the entries in 
the Gateway Structure may be web server specific. This 
information includes standard CGI variables, Cookies, Post/ 
Get data and additional security relevant data. This data is 
then formatted in buffers and the buffers are then sent to the 35 
Gateways 320 (via pipes (Windows NT) or shared memory 
segments (UnixWare)). In the case of Windows NT, there are 
three writes to the security gateway 320, One write sends the 
packaged data variables, another write sends the Cookie 
information and the final write sends the POSTed data, if 4Q 
such data exists. This step is common for all web based 
gateways. 

Each gateway 320 is built by linking the gate. lib library 
304 into it and including the gate.h include file (not shown). 
The gate.h include file is where the Gateway Data Structure 45 
Gatelnfo (further described in FIG. 6) is defined. The WebTx 
gate. lib library 304 is a unique library in that it actually 
contains the main procedure for the gateway 320. This 
configuration allows WebTx to control a great deal of what 
is done by the various gateways (Setup, Process, and 50 
Cleanup). Part of the setup done by the WebTx gate library 
code .(gate .lib) 304 is to process the buffers that were sent to 
the gateway from the WebTx Web Server Extension DLL 
302. Basically, the Gatelnfo data structure 306 (as described 
in FIG. 6) is set up and sent by this processing, via interface S5 
318. Also, within the WebTx Gateway 320, routines are 
called to load the views that are associated with the service 
being called. 

For the SGate gateway 320, there are two views loaded at 
this time. The first view loaded is the security service view 60 
(secsvc_view). This view is populated with data from the 
Gatelnfo data Structure 306 as well as being processed by 
the Temple te.c code. The Templete.c code is the standard 
routine for loading a view. The second view loaded is 
whatever view specific information the user decides to use 65 
with the Open OLTP end service. This second view infor- 
mation is loaded via the Templete.c code. 
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The SGate gateway 320 first sends the security service 
view (secsvc__view) information to the OPEN/OLTP secu- 
rity end service. If the user is authenticated by the security 
end service, the SGate gateway 320 then sends the end user 
view data. After the SGate gateway 320 passes the view data 
to the enterprise OLTP end service, the gateway 320 will 
await a reply from the Open OLTP end service that the 
requested task has been successfully completed. After a 
reply is received by the WebTx Gateway 320, the Gateway 
320 returns Cookie and Open OLTP end service output 
information back to the WebTx Web Server Extension 302 
via interface 316. The WebTx Webserver Extension 302 
then sets the Cookie information, if supplied by the end 
service, and returns the Cookie and Open OLTP end service 
output information back to the web server 300, so that the 
information can be returned to the requesting browser. 

FIG. 4 is a flowchart illustrating a step-by-step process 
flow through the SGate transaction gateway. The SGate 
gateway is designed to call an enterprise-based OLTP secu- 
rity service to authenticate a user request then pass the 
request through to another OLTP service (otherwise known 
as the OLTP end service). 

In step 400, the SGate gateway receives input data from 
the WebTx Web Server Extension Dynamic Link Library 
(DLL). In step 402, the SGate gateway processes the input 
CGI data variables and loads the Gatelnfo Data structure, 
both of which were passed to the gateway from the WebTx 
Web Server Extension. 

Next, in step 404, the SGate gateway checks any input 
cookies to see if there is a pre-existing authentication cookie. 
The SGate gateway also checks POSTed data for authenti- 
cation information. POSTed authentication information 
always overrides Cookie authorization information. If there 
is no authentication information passed through either the 
Cookies or POSTed data, an error message is issued at step 
406. 

Otherwise, if authentication information is present, pro- 
cessing proceeds to step 408, where the SGate gateway then 
populates the security service view (secsvc_view) and 
custom Open OLTP end service view. Next, at step 410, the 
SGate gateway opens a conversation with the enterprise- 
based Open OLTP Security Service. 

At step 412, the SGate gateway then sends the secvc_ 
view and additional Cookies to the OLTP Security service 
and waits for a reply from the security service. In step 414, 
if an unsuccessful reply is received by the security gateway 
from the Security Service, an error message is issued at step 
406, and processing is terminated. However, if a successful 
reply is received from the security service, processing con- 
tinues at step 416, where the custom Open OLTP end service 
view is sent to the enterprise based OLTP end service. The 
security gateway then waits for a reply from the OLTP end 
service. 

At step 418, if a unsuccessful reply is received from the 
Open OLTP end service, an error message is issued at step 
406 and processing is terminated. Otherwise, an authenti- 
cation cookie is created at step 420. 

Next, at step 422, the authentication cookie and the Open 
OLTP end service output is sent back to the web server so 
that the information can be sent to the requesting browser. At 
step 424, the conversation is closed with Open OLTP and the 
SGate gateway is reset for the next request. Finally, at step 
426, processing is completed. 

FIG. 5 is a flowchart illustrating the computer algorithm 
utilized by the SGate transaction gateway program. The 
SGate gateway is designed to call an enterprise -based OLTP 
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Security Service to authenticate a user request, then pass the 602, which is the third and final part of the informational 

request through to another OLTP service (also referred to as data structure. The Cookielnfo structure 602 contains point - 

the OLTP end service). The first step in the SGate algorithm ers to a defined number of possible cookies used for both 

is to check for pre-existing authentication cookies, as shown input and output. Cookielnfo 602 is described in more detail 

at step 500. When a user issues a secure transaction request, 5 below. 

three types of data are passed to SGate: 1) request input data, The Gatelnfo structure 600 contains an integer variable 

2) request environment variables and 3) request cookies. called i\Vr_Cookies, shown at 622, which if set to a 

These three types of data are sent to SGate. More non-zero value by the gate, on output, the Web Server 

specifically, the following data is sent to SGate: 1) an Extension DLL sends the Cookie information to the client 

authentication buffer containing authentication information 10 brow f r of the ™ l «s™n. The Cookie information jhat 

and request environment variables and the name of the * wn " e * ' omes *? m tl ! e . Cookielnfo structure 602 further 

OLTP end service, 2) request cookies (one at a time) and 3) d ^ cr ^ cd t bcl °^ If Co f* ^formation is to be written the 

j • J . r j *• t t \ . ' iWr_Cookies flag must be set prior to the first transmit. 

OLTP end service data formatted trom the request input „ , r * r . L1 ... 

^ t Gatelnfo 600 also contains an integer variable called 

' , . .„ response control (Resp_Control), as shown at 624, which 

Once a user has been authenticated, SGate will write 15 CQntains a y ^ {Q how tQ s {Uc ^ A 

authentication information to a Cookie that is used on yalue of „ Q „ ind[ca(es ^ n6 a » ^ u the « nor _ 

subsequent requests to save the user the hassle of repeatedly mal „ case whe ^ for examplC( HTML fe {Q be sent tQ lhe 

inputting authentication information. web browser A value of « r indicates that the gate requests 

After the algorithm has checked for pre-existing Cookies, authentication. A value of "2" indicates that even though 

the algorithm next populates two OLTP view buffers, one 20 contro] wag passed tQ ^ ^ (he gate wants tQ indicate t0 

containing information for the OLTP Security Service tne web server that it reaIly did not perforrn any processing 

(secsvc_view) and the other containing data for the and thal the request shoil , d be passed through to the nexl 

requested OLTP end service, as shown in step 502. service. This is only applicable to the Netscape family of 

The algorithm next opens a conversation with the OLTP weD servers. When a value of 1 or 2 is used, any data that 

Security Service, sending the authentication buffer, as 25 may have been setup by the gate is ignored (i.e., not sent to 

shown in step 504. In step 506, the algorithm then sends any the browser). 

request cookies to the OLTP security service. The Gatelnfo Structure 600 also contains an ASCII text 

After performing steps 504 and 506, the algorithm goes fi e id called Resp_ContentType, shown at 626, which is the 

into an idle state, waiting for an authentication reply from content type for the response. For example, this field may 

the OLTP Security Service, as shown at step 508. After an contain the string value "text/html". This field is required 

authentication has been successfully received by SGate, the anc j milst be set prior to the first transmit, 

algorithm then sends the OLTP end service data (this is the Finally, the Gatelnfo Structure 600 contains two pointers 

customer selected view data) to the Open OLTP Security (pTmp_userl and P Tmp_user2), shown at 628 and 630 

Service, as shown at step 510. ^ respectively. These pointers 628 and 630 are set aside for the 

Once again, SGate goes into an idle state; waiting for a custom gateway developer. Pointers 628 and 630 may be 

reply from the OLTP end service, as shown at step 512. Once usec j to point to the data buffers that the gateway sends back 

a reply is received from the OLTP end service, SGate next to t he web server via the transmit procedure. It is up to the 

creates an authentication cookie (if the request is gateway to do any memory allocation/deallocation for the 

successful), as shown at step 514. Finally, SGate will finish ^ buffers which are pointed to by these pointers, 

processing the reply received from the OLTP end service, ^ R eq Vars structure 604 contains pointers which point 

and return the end service output to the web server, as shown t0 tne stan d ar d CGI data variables provided by the web 

in step 516, server. If no data was provided by the web server for a 

FIG. 6 is an illustration of the data structures utilized by particular variable, its pointer will be null. There is no 

the WebTx custom gateway. There are three primary data 45 attempt here to describe the actual contents of each variable 

structures that will be visible within a gateway developed for due to the fact that the contents may vary slightly by web 

WebTx: Gatelnfo 600, Reqvars 604, and Cookielnfo 602. server. All of the data pointed to by these pointers should be 

The main data structure is Gatelnfo 600. The Gatelnfo treated as read only. WebTx will not look at these pointers 

structure contains an integer called argc and an array of or their data on the return to the WebTx Web Server 

pointers called argv, as shown at 612. Argc is the number of 50 Extension DLL. 

arguments passed to the gateway at execution time. Argv is * The Cookielnfo Structure 602 contains pointers which 

an array of pointers to the arguments passed to the gateway. point to the maximum number of Cookies received by the 

The Gatelnfo structure 600 also contains a pointer server from the client browser. Upon entry to the gateway, 
(pGate__in__data) to the gate input data buffer, also known this structure will contain any Cookies sent from the client's 
as the request data, as shown at 614. This pointer will be the 55 web browser, if any. There is no guarantee that these are the 
POSTed data if the method from the HTML form was POST specific Cookies that the gateway may be looking for. If the 
WebTx does not do anything with this data, it is passed iWr__Cookies variable 622 is non-zero when the first Trans- 
straight through to the gateway. Gatelnfo 600 also has an mit function is called, WebTx sends one Cookie to the client 
element which contains the number of bytes of data in the browser for the current session. Thus, the server will accept 
buffer pointed to by pGate_in_data, as shown at 616. 60 U p to 20 Cookies from the browser, but only one Cookie is 

The Gatelnfo structure 600 also contains an element 618 sent back to the browser from the gateway/server, if the 

which is a structure of pointers to CGI/HTTP request "write cookie" flag (iWr_Cookies) is set. 

variables called ReqVars 604, which is the second major part There is no guarantee that the client browser will accept 

of the informational data structure, ReqVars 604 is described the Cookie information. This means on input to the gate, 

in more detail below. 65 Cookies that are expected may or may not be present. The 

Gatelnfo 600 also contains a an element 620 which is custom gateway developer should be aware of this, and may 

structure of pointers to HTTP Cookies called Cookielnfo have to code for this possibility. 
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For each cookie pointer which is non-null, a Cookie will 
be written. The data pointed to by the Cookie pointer should 
have the following format: 

"NAME-VALUE; expires-DATE; path-PATH; 

domain=DOMAIN_NAME; secure" 
As an illustrative example: 

"PRODUCT=WebTx; pauWfoo; 

expires-Tuesday, 25 May 98 23:00:00 GMT' 

FIG. 7 illustrates a functional, block-level overview of the 
enterprise -based On -Line Transaction Processing (OLTP) 
System security service of the present invention. In broadest 
terms, WebTx Software 710 and 714 (available from Unisys 
Corporation) provides a security gateway to act as an On 
Line Transaction Processing (OLTP) client that packages 
input from a Web page (coded in HTML) and establishes a 
conversational connection with an OLTP security service 
720. In conversational communication, client programs 
establish logical connections with service routines and con- 
duct dialogues. Dialogues occur as one program sends data 
and the other receives data. During conversations, clients 20 
and service routines can exchange the sending and receiving 
roles. 

The OLTP security service 720 authenticates the caller 
and calls the requested OLTP end service 722. The security 
service 720 is a Unisys provided code module in the form of 25 
a template. It is intended that a customer can modify the 
service to suit their particular needs. The WebTx security 
gateway 714 can operate in a Windows NT or UnixWare 
environment 702, using HTP/IC or Pathway 716 to com- 
municate with OLTP software 718. 30 

To begin the process, a Personal Computer 700 based web 
browser 760 presents an HTML page that requests the 
following minimally required information from the user: 
user-id, password, and OLTP end service information. The 
HTML page can be customized to embed or request other 
security information elements, such as a new password, 
account number, project-id, clearance level, and compart- 
ment set. 

When the HTML page is submitted by the user, the web 
server program 708 passes the following information to the 
WebTx Server Extension DLLs 710, and ultimately, the 
WebTx gateway 714: user-id, password, OLTP end service 
information, OLTP security service request, OLTP end ser- 
vice name to call, end service input/output buffer types, and 
browser CGI variables. 

The WebTx security gateway 714 acts like an OLTP client 
and packages the following information in an internally 
defined input buffer (secvc_view): security information, 
CGI variables, and the OLTP end service name 722 to be 
called. The buffer is used on a send-only conversational 
connection to the OLTP security service 720. The WebTx 
security gateway client 714 passes any Cookies associated 
with the Internet user, one at a time, to the security service 
720. A maximum of 20 Cookies may be passed in this 
manner. After the final Cookie is sent, the gateway 714 
passes control of the conversation to the security service 
720. The WebTx security gateway 714 then waits for an 
authentication response from the security service 720. 

When the security service 720 is called from the WebTx 
security gateway 714, the service calls the OS 2200 Open/ 
OLTP Transaction Manager (OLTP-TM2200) subsystem to 
enqueue the authentication request based on the security 
information provided. OLTP -TM 2200 is the Unisys Corpo- 
ration implementation of an X/Open compliant transaction 
manager (TM) for the OS 2200 operating environment of 
ClearPath HMP IX Series with UNIX servers and OS 2200 
Series systems. The security service 720 waits until the 
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Open CMS (OCMS) activity processes the request using the 
SESSIONSCTRL interface. 

By way of definition, the SESSIONSCTRL interface can 
authenticate the following security information: user-id, 
password, new password, account, project, clearance level, 
and compartment set. Authenticate means to pass the OS 
2200 sign on requirements for the security level of the 
accessed system. Using the SESSIONSCTRL interface to 
authenticate security information creates an open Transac- 
tion Processing (TIP) session. This session is immediately 
terminated and not utilized by Open/OLTP software. The 
interface is called only to verify that the user can pass the 
operating system sign-on checks. It means, however, that the 
user-ids of all callers must have access to the TIP environ- 
ment. 

The Open CMS (OCMS) activity is an OLTP-TM2200 
real time activity that is started as a task under the transac- 
tion management system control (TMSC) run. This activity 
dequeues authentication requests placed on the subsystem 
request queue by a security server and calls the SES- 
SIONSCTRL interface to process the request. To call the 
interface, OCMS must register as an open CMS type and 
establish a routing output queue (ROQ) and a position 
identifier (PID) pool based on configuration information. 
The results for a processed authentication request are placed 
on the ROQ by the operating system. When authentication 
results are available, the OCMS activity removes the result 
from the ROQ and delivers the reply to the waiting security 
server. 

If the authentication request is successful, the security 
service sends a successful condition to the waiting WebTx 
security gateway client 714, obtains the end service input 
buffer from the gateway client, calls the end service 722, and 
returns the end service results to the WebTx security gate- 
way client. If the authentication request is unsuccessful, the 
security service 720 returns a failure condition to the WebTx 
security gateway 714 and provides a message buffer indi- 
cating the error. 

Back at the waiting security gateway 714, if the security 
service 720 authentication request is returned as successful, 
the gateway 714 allocates an end service input buffer based 
on the previous HTML information, fills in the user supplied 
data, sends the end service input buffer to the security 
service, obtains results upon completion of the end service 
transaction 722, and forwards the end service results to the 
web browser 706. 

If the security service 720 authentication request is 
returned as unsuccessful to the waiting security gateway 
714, the security service 720 returns a failure condition and 
provides a message buffer indicating the error. 

FIG. 8 is a flowchart illustrating the enterprise-based 
On-Line Transaction Processing (OLTP) System security 
service template module. The security service template 
module can be built into an OLTP batch, Transaction Pro- 
cessing (TIP), or High-Volume Transaction Processing 
(HVTIP) server to request authentication of user security 
information which minimally consists of a user-id and a 
password. The security server will be invoked by a 
tpconnect( ) call (to establish a conversational service 
connection) from the WebTx security gateway client, as 
shown in step 800. 

After the security service view information is obtained by 
the security service through the security gateway tpconnect( 
) call 802, the security service will loop on the tprecv( ) call 
(receives a conversational message) to obtain up to 20 
Cookies associated with the web user, as shown in step 804. 
The Cookie buffers are sent in as X_OCTET strings and can 
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be recorded or used as needed. The X_OCTET type buffer 
is an array of bytes (characters). The contents of an 
X_OCTET typed buffer are completely defined by the 
application. This typed buffer is used for application pro- 
grams that internally define the structure of the data to be 
exchanged. 

After the Cookies associated with the web user have been 
obtained, the security service code then calls the OLTP 
subsystem SESSENQ( ) gate or function to stage the authen- 
tication request, as shown in step 806. The authentication is 
performed by the operating system SESSIONSCTRL inter- 
face. The OLTP open cms activity, ocrns, services the 
authentication request by dequeuing it from the subsystem 
queue and calling the interface on behalf of the server. 
Authentication information is provided via the authinfo 
structure. The server will wait until the authentication 
request is complete. 

Next, at step 808, a check is made by the security service 
for successful authentication from SESSENQ. If the request 
was successful 810, check for a password change 814. If a 
password change was made 818, the end service is not called 
so that the user can be notified of the password change 822. 
The password change information is returned, and the ser- 
vice is stopped 824. 

If the authentication was successful, and there was no 
password change 820, control of the conversation is sent 
back to the gateway as an indication of successful 
authentication, as shown at 826. Next, the information that 
is to be passed to end service needs to be retrieved from the 
gateway 828. To do this, the function tprecv( ) is sent to the 
gateway using a dummy buffer. This dummy buffer will be 
reallocated within the call to the actual type of buffer needed 
by the end service. This automatic reallocation allows the 
security service to be used as generic front end to any end 
service which requires authentication. 

Next, the security service code does a tpalloc( ) of the 
output buffer for the tpcall( ) (sends a service request and 
waits for the reply), as shown in step 830. This buffer is also 
a dummy buffer which is automatically reallocated with the 
tpcall( ). This automatic reallocation allows the security 
service to be used as a generic front end to any end service 
which requires authentication. 

Next, the end service is called through a tpcall( ). Finally, 
at step 834, the security service code returns a success or 
failure of the end service flag, along with end service 
information to the client. 

If the authentication from SESSENQ was unsuccessful 
812, the service is ended 816. 

Having thus described the preferred embodiments of the 
present invention, those of skill in the art will readily 
appreciate that the teachings found herein may be applied to 
yet other embodiments within the scope of the claims hereto 
attached. 

We claim: 

1. In a data processing system, the improvement com- 
prising: 

at least one web browser interconnected to at least one 
The enterprise -based On-Line Transaction Processing 
(OLTP) System via a transaction gateway; 

means for exchanging Cookie information and CGI vari- 
ables between said web browser and said enterprise - 
based On-Line Transaction Processing (OLTP) System; 

wherein upon a web request a web server formats said 
CGI variables and said Cookie information from said 
request into a requesting long string which is passed to 
a middleware Web Server Extension; and 

wherein said middleware Web Server Extension under- 
stands the format of said requesting long string, and 
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re-packages variables from said requesting long string 
into a requesting array which is passed to the transac- 
tion gateway associated with said request. 

2. Adata processing system; according to claim 1 wherein 
S said transaction gateway builds a input view file using the 

Cookie and CGI variables from said requesting array, then 
passes said input view file to an On-Line Transaction 
Processing (OLTP) service application. 

3. Adata processing system according to claim 2 wherein 
30 said On*Line Transaction Processing (OLTP) service appli- 
cation returns an output view file to said transaction gateway 
upon completion of said request. 

4. A data processing system according to claim 3 wherein 
said transaction gateway unpacks said output view file 
returned from said gateway, populates a web page with 

15 information from said output view file, and builds a return 
Cookie wherein said web page and return Cookie are passed 
back to said middleware Web Server Extension. 

5. Adata processing system according to claim 4 wherein 
said middleware Web Server Extension passes back said 

20 web page and said return Cookie to said web server. 

6. Adata processing system according to claim 5 wherein 
said web server passes said return Cookie and said web page 
back to said web browser. 

7. Adata processing system according to claim 1 wherein 
25 said interconnection is the Internet. 

8. Adata processing system according to claim 1 wherein 
said enterprise On-Line Transaction Processing (OLTP) 
system is a commercial mainframe computer. 

9. Adata processing system according to claim 1 wherein 
30 said transaction gateway is an interface which allows Java 

applets running in a web browser to make program calls to 
an OLTP-style application running on said enterprise OLTP 
system. 

10. A data processing system according to claim 1 
35 wherein said transaction gateway is an interface which 

allows a web browser running in a Distributed Component 
Object Module (DCOM) environment to make program 
calls to an OLTP-style application running on said enterprise 
OLTP system. 

40 11. Adata processing system according to claim 1 wherein 
said transaction gateway is a security gateway which passes 
said Cookie information and CGI variables to a security 
service executing on said enterprise OLTP system. 

12. A data processing system according to claim 1 
45 wherein up to 300 said Cookies can be stored at a client at 

one time, with a 4 kilobyte limit per said Cookie, and a limit 
of 20 said Cookies per server and domain. 

13. In a data processing system having at least one web 
browser interconnected to at least one Enterprise-Based 

5Q On-Line Transaction Processing (OLTP) System, the 
improvement comprising: 

a security gateway component which manages commu- 
nications between said web browser and said 
Enterprise-Based On-Line Transaction Processing 
55 (OLTP) System; 

wherein upon issuance of a web request, said web browser 
passes Cookie information and CGI variables to said 
security gateway; 
wherein said Cookie information and CGI variables are 
60 packaged by said security gateway into an input view 
file; and 

wherein an authentication request is passed from said 
security gateway to a security service residing on said 
enterprise-based On-Line Transaction Processing 
65 (OLTP) System. 

14. A data processing system according to claim 13 
wherein upon successful validation of said authentication 
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request by said enterprise -based OLTP security service, a means for passing information between said web browser 

response will be passed from said security service to said and said Enterprise-Based security service component 

security gateway authorizing said request. via said security gateway component, wherein said 

15. A data processing system according to claim 14, information comprises Cookies and CGI Variables, 
wherein upon receiving said request authorization from said s 25. A data processing system according to claim 24 
security service, said security gateway builds a view buffer wherein said web browser passes a user-id, OLTP end 
associated with a OLTP service application requested, and se ™f* ^formation, an OLTP security service request, an 
passes said view buffer to said OLTP service application. ^ end ™™ {0 t cal1 ' e ^ r T! ce ^ out P u j 

16. A data processing system according to claim 14, buffer ^ and said Cookies and CGI Variables to said 
wherein if no request authorization is received by said io secunty gateway component, v ia a web server. 

security gateway from said security service for said request, . d » ta P rocess *ng ^™ according to claim 25 

access to a OLTP service application is denied. wherein said secunt y gateway component packages a set of 

17. A data processing system according to claim 13, sec , u^ A t T y ^ formatl0n, S n ?• . 

,„u^ M „ ,™ ^...^ rt „ n Jz , TIQ u said OLTP end service name into an internally denned input 

wherein said secunty gateway runs on a commercial web .«.*..». . . . • . 

„ . - buffer which is passed to said secunty service component, 

server machine. 15 r . J r . 

18. In a data processing system having at least one web L 27 ' . da j a P^^essing system according to claim 26 
browser interconnected with at least one Enterprise-Based wherein sa ' d secunt y S atewa y said Cookies > one at a 
On-Line Transaction Processing (OLTP) System, the time to said security service component, up to a maximum 
improvement cornnrisine:' 0 s Cookies. 

. . . ~ n 28. A data processing system: according to claim 27 
a secunty service component residing on said OLTP 20 ccci of an authentication req uest from said 
System which validates a request from said web security gateway, said security service calls an OLTP Trans- 
browser, action Manger 2200 subsystem to enqueue said authentica- 
wherein said security service is a C code module written tion request based on the security information provided. 

in the form of a standard OLTP-TM2200 service; and ^ 29. A data processing system according to claim 28 

wherein upon receipt of a an authentication request from wherein said enqueued authentication request is dequeued 

said WebTx security gateway client, said security ser- by an Open CMS (OCMS) activity which calls a session 

vice calls the standard OLTP-TM2200 service sub- control interface to process the request, 

system to enqueue said authentication request based on 30. A data processing system according to claim 29 

the security information provided. 3Q wherein said session control interface can authenticate user- 

19. A data processing system according to claim 18 id, password, new password, account, project, clearance 
wherein said enqueued authentication request is dequeued level and compartment set security information. 

by an Open CMS (OCMS) activity which calls a session 31. A data processing system according to claim 30 

control interface to process the request. wherein results from said authentication requests are placed 

20. A data processing system according to claim 19 35 on a routing output queue (ROQ) by the operating system, 
wherein said session control interface can authenticate user- such that said OCMS activity removes said results from said 
id, password, new password, account, project, clearance ROQ and delivers said results to said security service, 
level and compartment set security information. 32. A data processing system according to claim 31 

21. A data processing system according to claim 20 wherein if said authentication request is successful, said 
wherein results from said authentication requests are placed 4Q security service sends a successful condition to said security 
on a routing output queue (ROQ) by the operating system, gateway client, calls a function to obtain an end service input 
such that said OCMS activity removes said results from said buffer from said middleware security gateway, calls an end 
ROQ and delivers said results to said security server. service application passing said end service input buffer, and 

22. A data processing system according to claim 21 returns results from said end service to said security gateway 
wherein if said authentication request is successful, said 45 client. 

security service sends a successful condition to said security 33. A data processing system according to claim 31 

gateway client, calls a function to obtain an end service input wherein if said authentication request is unsuccessful, said 

buffer from said middleware security gateway, calls an end security service returns a failure condition to said security 

service application passing said end service input buffer, and gateway client, and provides a message buffer explaining 

returns results from said end server to said security gateway 5Q said failure. 

client. 34. In a data processing system having at least one web 

23. A data processing system according to claim 21 browser and at least one enterprise-based On-Line Transac- 
wherein if said authentication request is unsuccessful, said tion Processing (OLTP) System, a method for exchanging 
security service returns a failure condition to said security information between said web browser and said enterprise- 
gateway client, and provides a message buffer explaining 5S based On-Line Transaction Processing (OLTP) system 
said failure. wherein said web browser and said enterprise-based OLTP 

24. In a data processing system having at least one web system are interconnected by a workstation based security 
browser interconnected to at least one Enterprise- Based gateway, comprising the steps of: 

On-Line Transaction Processing (OLTP) System, the receiving an OLTP transaction request and associated 

improvement comprising: 6Q Cookie and CGI variable information from said web 

a security service component residing on said OLTP browser via a middleware server; 

System which validates all requests from said web building a view file using said Cookie and CGI variable 

browser; information at said security gateway; 

a security gateway component which manages commu- calling an enterprise based OLTP security service from 

nications between said web browser and said 65 said security gateway; 

Enterprise-Based On-Line Transaction Processing waiting for a validation response from said OLTP security 

(OLTP) System; and service at said security gateway; 
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processing said validation response from said security 

service at said security gateway; 
forwarding an end service view file from said security 
gateway to an enterprise OLTP end service upon suc- 
cessful validation of said request; and 
returning a set of end service results to said web browser 
via said security gateway upon processing completion 
of said enterprise OLTP end service. 
35. In a data processing system having at least one web 
browser interconnected to at least one enterprise-based 
On-Line Transaction Processing (OLTP) System via a secu- 
rity gateway, a method for validating a transaction between 
said web browser and said enterprise -based On-Line Trans- 
action Processing (OLTP) system, via an enterprise-based 
security service, comprising the steps of: 

sending an OLTP transaction request and associated 
Cookie and CGI variable information from said web 
browser to a workstation based security gateway via a 
middleware server; 



,080 Bl 

20 

receiving an authentication request and a security view 
file from a workstation based security gateway at said 
enterprise based security service; 

processing said authentication request by calling a 
secured operating system interface from said enterprise 
based security service to authenticate information from 
said security view file; 

returning said authentication information to said worksta- 
1 tion based security gateway; 

forwarding an end service view file from said security 
gateway to an enterprise OLTP end service upon suc- 
cessful validation of said request; and 

1 returning a set of end service results to said web browser 
via said security gateway upon processing completion 
of said enterprise OLTP end service. 

* * * * * 
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